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SMALL BUILDING AUTOMATION CONTROL SYSTEM 
BACKGROUND OF THE INVENTION 
This application claims priority from U.S. Provisional Application No. 60/261488 
for METHOD, SYSTEM AND APPARATUS FOR SELF-CONFIGURING NETWORK filed 
5 on January 1 2, 2001 by Arnold et al. 

The present invention relates to building control systems, and more particularly to 
control systems for integrating and controlling the operation of various automated applications 
within a small building. 

In large commercial buildings sophisticated PC networks are used to automate 

1^ and control the operation of HVAC and lighting to assure comfort and efficiency. These 

: , ■; O 

I ;Q various Intelligent Building Systems (IBS) may also be configured to monitor the safety of the 

, «P property, contents and people in the building. Whether the building is occupied or empty, these 

} ? * IBS systems keep watchful control over the fire and security status, the comfort and energy 

; 13 consumption, and the effects of changing weather or occupancy to efficiently operate the entire 

\ physical plant. Specially trained engineers, programmers, commissioning and maintenance 

• ■ Q technicians design, program, install and maintain these expensive and complex multiple IBS 

) iU- 

systems. After installation, the complexity of these IBS systems requires that they be operated 
by trained building technical and security staff. Typically, this staff is dedicated to the use and 
operation of the various IBS. 
20 These IBS systems integrate, at a host level on a PC workstation(s), the 

individual computerized control functions of access, security, HVAC, lighting, and fire 
protection in an effort to provide occupant comfort, safety, and convenience, both during and 



l 



after working hours. These IBS systems adjust the building's various applications based upon 
preprogrammed instructions and can provide management reports of abnormal conditions 
(alarms), property usage and energy consumption, operating trends and maintenance 
information. In a complex IBS, these systems may turn on lights, adjust the HVAC for 
5 comfort, turn security systems to the occupied status, enable elevators, and compensate for 
prevailing weather at the beginning of a day. At the end of the day these complex IBS's may 
reverse the process to maximize efficiency, minimize energy cost and provide for occupant and 
property protection. The interaction of preprogrammed parameters, real time sensor inputs, 
and operating events make these IBS's adjust automatically to schedules, occupant 

4g requirements, and the need of the management for timely indications of, and interactions for, 
i° planned and exceptional circumstances. 

j © Unfortunately, this level of computerized control and machine interaction is 

^ expensive and currently affordable only in large buildings, for example, buildings of 

• © 

; jj^" approximately 200,000 square feet and larger. The cost of putting a PC into service alone can 

15i mean that these BBSs cannot compete within the cost constraints in small buildings. Putting 

;.|D 

: Iff. aside the complexity issues attendant to a PC based IBS, widespread acceptance of these IBS in 
properties with a $10,000 control budget is unexpected because the cost of adding a PC and 
associated software alone adds $3,000 - 30% cost premium to the traditional controls budget. 
As a result, the control technology available to smaller buildings has been limited to the kinds 

20 of discrete stand-alone HVAC control or lighting control, or security system that is used in 
residential property. For example, small building typically include little more than a timing 
device for each HVAC unit, lighting control at each lighting panel, and separate burglar alarm 
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type security. Each device operates independent of the other controls in the building and each 
has no central point of reporting or adjustment. This means that every change in use or 
schedule must typically be entered again and again into each controller by the maintenance 
personnel. Changes of schedule, or season, or use result in tedious and laborious modification 
to the various discrete applications. In many cases, operating parameters are selected as a 
matter of convenience for the maintenance person with little concern for efficiency, cost 
avoidance, or occupant convenience. 

SUMMARY OF THE INVENTION 
The aforementioned problems are overcome by the present invention wherein a 
control system for use in small buildings is provided with a local control interface that is 
preprogrammed with profiles of various application controllers types which permit 
autoconfiguration of the application controllers. The local control interface includes means for 

obtaining the application controller type from each new application controller. The local control 
< — . ■ 

interface uses the controller type as a key to access the pre-stored profile for the specific 
application controller type. The profile provides the local control interface with all control 
variable information necessary to configure the application controller on the local control 
interface. 

In a preferred embodiment, the local control interface also includes means for 

obtaining an application controller profile directly from the application controller at the time of 

configuration. T his mechanism is particularly useful when the profile for a specific application 

controller is not contained in the pre-stored profile database. For example, the local control 

interface may acquire profiles directly from application controllers that are freely programmable 

for custom applications not pre-stored in the local control interface's profile database. 
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The present invention also provides a method for configuring an application 
controller. In a preferred embodiment, the application controllers include a service pin that is 
actuated to initiate the automated configuration process. Upon activation of the service pin, the 
application controller transmits its processor ID to the local control interface. In response, the 
5 local control interface assigns a unique system ID to the device and polls the application 
controller to determine, among other things, its cont roller type . Once the controller type is 
determined, the local control interface retrieves the pre-stored profile for that specific controller 
type. The profiles include all information regarding the control variables associated with a 
particular controller type. 



1Q In a preferred embodiment, the control interface and various application 

■ |p controllers communication over a conventional communications network with explicit messages 

£ using explicit addressing. The control interface is preferably preprogrammed with definitions of 

i { Ifej' the various explicit messages that may be sent or received by the control interface. Similarly, 



^ each application controller is preferably preprogrammed with definitions of the various explicit 
messages that may be sent or received by that application controller. 
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In a more preferred embodiment, the local control interface includes means for 

'ill 

periodically sending ping message to each of the application controllers. Depending on the type 
of application controller, the ping message ma y include control variables that affect operation of 
the application controller. The application controllers i nclude means for updating their c ontrol 
20 variables in acco rdance with values presented in the ping message. In addition, the application 
controllers each include means for sending a response to each ping message. The response 
confirms that the application controller is still available on the network and, depending on the 
application controller, may return to the local control interface the value of one or more control 
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variables that may be forwarded to or otherwise affect operation of other application controllers. 
The data structure of the ping message for each controller type is preferably preprogrammed into 
the local control interface, thereby eliminating the need for user input to define these data 
structures at the time of configuration. 
5 In an even more preferred embodiment, the local control interface is pre- 

programmed to provide integration between applications of various types. In general, the 
controller interface is preprogrammed to make appropriate changes to one application controller 
in view of information received from another application controller. The control interface 
preferably includes sufficient programming to provide integration between HVAC applications, 
10^ lighting applications, security alarming and card access applications. Even more preferably, the 
. 2 controller interface will also be preprogrammed to provide integration between public utility 
£ demand meter reading applications and asset monitoring applications, for example, applications 
> ly that work with RF asset tags or bar codes to monitor movement and/or status of various assets, 

■ m 

* and alarm status from a fire alarm system. 

In yet another preferred embodiment, the control syste m includes a network 
; ip f server interface that permits the control system to be operated and monitored using conventional 
Internet or dial-up access capabilities. The local control interface provides explicit messages that 
permit other compatible devices to read and write to the local control interface remotely. 

The present invention provides a cost effective small building control system that 
20 is relatively simple to install, configure and operate. The present invention preferably includes a 
dedicated local control interface that replaces the high-cost PC conventionally used to configure 
and/or operate a conventional IBS. The dedicated controller includes only those components 
necessary to configure and control the system, and is therefore less expensive than conventional 
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PCs. Because the local control interface is preprogrammed with profiles for the various 
application controllers supported by the system, the control system permits self-configuration of 
the application controllers. The local control interface also permits grouping of various 
application controllers, including application controllers of different types. This permits group 

5 toggling of occupancy status and potentially other variables, thereby permitting a certain level of 
integration between applications of differing types, for example the control of lighting and 
HVAC applications in response to access events. A further level of integration is provided by 
the explicit messages sent by the local control interface. These messages transfer the value of 
control variables between application controllers, including application controllers of different 

10 types. The network server interface also permits dial-up or Internet-based control and therefore 

;g provides additional flexibility in monitoring and controlling the system. 

These and other objects, advantages, and features of the invention will be readily 

O . 

^ understood and appreciated by reference to the detailed description of the preferred embodiment 
•q and the drawings. 

j£ BRIEF DESCRIPTION OF THE DRAWINGS 

P 

:J3 Fig. 1 schematic diagram showing the various components of a control system in 

m 

accordance with a preferred embodiment of the present invention; 

Fig. 2 is a block diagram illustrating the components of the local control interface; 
Fig. 3 is a block diagram illustrating the components of the HVAC and lighting 

20 application controllers; 

Fig. 4 is a block diagram illustrating the components of the access control 

application controller; 

Fig. 5 is a schematic diagram of an ASM-1; 
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Fig. 6 is a schematic diagram of an LCU-1; 
Fig. 7 is a typical thermostat module system diagram; 
Fig. 8 is a representation of the data structure for an HVAC control ping; 
Fig. 9 is a representation of the data structure for an HVAC response message; 
5 Fig. 10 is a representation of the data structure for an ACU control ping; 

Fig. 1 1 is a representation of the data structure for an ACU response message; 
Fig. 1 2 is a representation of the data structure for an ASM control ping; 
Fig. 1 3 is a representation of the data structure for an ASM response message; 
Figs. 14A-14B are a flow chart showing the steps of a preferred embodiment of 

1^ the automated configuration process; 

i/G 

Fig. 1 5 is a representation of the data structure for an access request message; 

. £ F^g- 1 6 is a representation of the data structure for an access response message; 

4 a 

» W Fig. 1 7 is a representation of the data structure for a door user message; 

- ^ Fig. 1 8 is a representation of the data structure for an alarm message; 

Fig. 19 is a representation of the data structure for an LCU control ping; and 

\ ilk 

I ijp Fig. 20 is a representation of the data structure for an LCU response message. 

•ilU 

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENT 
I. Control System Overview 

A schematic diagram illustrating the architecture of a control system according to 
20 a preferred embodiment is shown in Fig. 1 and generally designated 10. The control system 10 
is a distributed control system having a local control interface 12 and a plurality of application 
controllers 14, 15, 16 and 18 interconnected by a conventional communications network 20. The 
local control interface 12 manages the control system 10 providing direct digital control of the 
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application controllers. Each application controller controls operation of a corresponding 
application, such as HVAC application controller 14, card access/security application controller 
16, lighting application controller 18 and system-wide sensor controller 15. The application 
controllers are generally stand-alone controllers operating in accordance with various control 
variables. The local control interface 12 provides a user interface for monitoring system 
parameters, changing the value of control variables and managing alarms and events. Through 
this functionality, the local control interface 12 provides integration between application 
controllers 14, 15, 16 and 18, including application controllers of different types. The local 
control interface 12 is preprogrammed with profiles of the various types of application 
controllers 14, 15, 16 and 18 that are supported by the system 10, including the relevant control 
variables for each. Additionally, the local control interface 12 may acquire a profile from an 
application controller at the time of self-configuration, for example, if the application is 
unknown to the local control interface 12 or a new or customized version of the profile is 
available. Profiles may also be downloaded through the local control interface 12 or remote 
access such as the Internet or a dialed or direct connection. These profiles permit self- 
configuration of the application controllers. This specification describes a preferred embodiment 
of the present invention, providing sufficient detail for one skilled in the art to practice the 
claimed invention. Additional detail is contained in U.S. Provisional Application No. 
60/261,488 for METHOD, SYSTEM AND APPARATUS FOR SELF-CONFIGURED 
NETWORK, filed January 12, 2001, which is incorporated herein by reference. 
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II. Control System Components 

As noted above, the present invention is directed to a small building control 
system including a local control interface 12 and a variety of application controllers 14, 15, 16 
and 1 8 that communicate over a conventional communications network 20. 
5 A. Communications Network 

The communications network 20 may be any of a variety of conventional 
hardwire networks, for example, Ethernet or other hardwire networking technologies. The 
control system 10 is also suited for use with a wide range of wireless networking technologies, 
such as radio frequency, power line carrier, optical and other similar technologies. Further, the 
1^. control system 10 may include a combination of networking technologies. For example, as 
. .. g shown in Fig. 1, the system 10 may include a primary network section 20a and a network 
. 4= extension section 20b that are interconnected by communication interfaces 20c and 20d. The 
; ;|j present invention may also include capabilities for remote networking. Internet, point-of-sale 
; £j cash register systems, wide area networks and local area networks can be use for remote control 
: and monitoring of the control system 10. As shown in Fig. 1, the system 10 may include a data, 

j it 

) web page server 22 to provide an interface for various remote networking capabilities. These 
various networking technologies are well known to those skilled in the art and therefore will not 
be described in detail. 

B. Local control interface 
20 As noted above, the control system 10 is managed by a local control interface 12. 

The local control interface 12 may be implemented using a wide variety of circuit components 
and circuit layouts. Accordingly, the local control interface will vary from application to 
application. For largely cost reasons, the local control interface is preferably embodied in a 
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dedicated control device having only the necessary hardware components. Alternatively, the 
local control interface can be embodied in a PC, such as a. desktop, palmtop, or laptop. For 
purposes of disclosure, a preferred implementation of the local control interface 12 will now be 
described. 

In general, the local control interface 12 includes a display and touch screen 21, a 
main processor section 22, a network interface processor section 24, a local serial interface 
section 26, an LCD interface section 28, a touch screen interface section 30 and a power supply 
section 32. The local control interface 12 preferably includes a conventional color graphic 
ViVGA sized LCD display with an integral analog resistive touch screen for input and output 
The display and touch screen provide a graphical user interface ("GUI") for data entry and 
display. The local control interface 12 can alternatively include other types of touch screens or 
other conventional input and output devices, such as a keyboard. All user input is performed 
with the touch screen, primarily by touching buttons or icons on the display. The GUI preferably 
includes soft-keys which permit the user to navigate through menus as necessary to control and 
configure the system 10. 

Although the main processor section 22 will vary in design and configuration 
from application to application, in the described embodiment the main processor section 22 
includes an AM186EM 16 bit embedded microprocessor 40; two 2 Mbit FLASH 
reprogrammable firmware memory chips 42 that contain the program executed by the main 
processor; two 1 Mbit MC434000n static RAM chips 44 that provide memory for temporary data 
storage, database storage and communications buffers; an address decode section utilizing a 
GAL 16V8 programmable logic device 46 that provides input/output interfacing; a synchronous 
serial interface (not shown) is embedded within the AM186EM microprocessor to communicate 
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with touch screen controller 48; a nonvolatile Real Time Clock RTC 50; two software controlled 
status light emitting diodes 52 for the indication of program status and verification of reception 
of a network identification message; a clock 54 having a 20.0 Mhz crystal and discrete 
components that cause the AM186EM microprocessor to operate at the proper frequency. The 
5 main processor 22 preferably also includes an ADM691 A power-on reset controller 56 to ensure 
that the power supply is stable and within proper operating tolerances and that the AM186EM 
microprocessor is initialized properly. The ADM691A controller preferably includes a watch- 
dog timer to reset the AM186EM microprocessor in the event of a software hang-up. A battery 
switch-over circuit (not shown) permits the nonvolatile retention of the database in the event of a 

lf^ loss of power. The battery switch-over circuit includes a disabling device, such as an external 

."$3 

, jj jumper, that permits the battery back-up to be disabled for clearing the database as desired. The 

■ fS lf 

Jp database may also be cleared through an installer menu function in software on the local control 
f M interface. 

* The network interface processor section 24 provides an I/O space mapped 

interface to the Echelon LonWorks network and offloads certain low-level functions from the 

ill* 

; ; .Q AM186EM processor, such as low-level network protocol and driver functions. The network 
interface processor 24 generally includes an MC143150B1FU1 Neuron processor 58 or its 
equivalent that executes an Echelon-supplied software program (e.g. Neuron "C" Program); an 
AT29C010N FLASH reprogrammable firmware memory chip 60 to contain the Echelon- 

20 supplied software program; a 43256AGU static RAM chip 62 for temporary data storage and 
communication buffers; an address decode section 64; a service switch and LED (not shown) are 
connected to the Neuron processor to indicate the service status condition of the network 
processor; a power-on reset controller 56 (essentially shared with main processor section 22) 
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used to ensure that the power supply is stable and within proper operating tolerances; LED 
indicators 52 (shared with main processor section 22) to indicate the status of network activity 
and to indicate network processor transmission; and a clock 66 having a 10.0 Mhz. crystal and 
discrete components causing the Neuron processor 58 to operate at the proper frequency. The 

5 network interface processor section 24 also preferably includes an intercontroller network 
interface section 68 that supplies external network communications from the controller interface 
to the applications controllers. The network interface processor section 24 preferably includes an 
FTT10A Free Topology Transceiver (not shown) and its associated circuitry (not shown) and/or, 
an LT485 EIA485 differential transceiver (not shown) and its associated circuitry (not shown). 
1£ The specifications of the FTT10A transceiver are described in more detail in "Lon Works FTT- 
10A Free Topology Transceiver User's Guide," which is published by and available from 

;j£ Echelon Corporation, and is incorporated herein by reference. When the network interface 

U section 24 is used for only FTT10A communication, the FTT10A transceiver (not shown) is 

•ft 

* connected directly to the Neuron processor (not shown). When the network interface section 24 
is used for both FTT10A and EIA485 communication, independently or together, the FTT10A 
transceiver (not shown) is connected directly to an EIA485 transceiver (not shown) and on to the 
EIA485 multi-drop network. A one-shot multivibrator (not shown) and inverting Schmidt 
trigger (not shown) are used to supply a delayed enable signal to the transceiver from the data 
activity on the FTT10A transceiver. The EIA485 transceiver provides the network connection 
20 for the Neuron processor. Alternatively, either the FTT10A and/or the EIA485 on the preferred 
implementation, or a different interface such as a PLT22 power line transceiver could be used. 
The actual protocol used is the Echelon LonWorks Manchester-based (for FTT10A or EIA485 
interfaces) or the Echelon LonWorks special mode interface (for PLT22 or other power line 

12 
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interfaces). The Echelon LonWorks protocols are well known to those skilled in microcontroller 
designs. The technology that allows for simultaneous communication sharing between the 
FTT10A medium and the EIA485 medium is described in U.S. Patent 6,046,657 to Kikta, which 
is incorporated herein by reference. 

The local serial interface section 26 provides an interface between the main 
processor section 22 and a personal computer or CRT terminal to be used for initialization and 
database downloading. The local serial interface section 26 preferably includes a MAX202 
EIA232 interface transceiver (not shown). The serial port used for communications between the 
main processor section 22 and the PC is embedded within the AMI 86 microprocessor. 

The LCD display interface section 28 utilizes an SED1374 memory mapped LCD 
controller 70 to drive the color LCD module. This device perfonns all the data stream 
formatting, color look-up table translation, and timing signals needed by the display. A 
GAL16V8 programmable logic device (not shown) provides the color/monochrome and 4/8 bit 
display data path translation as required by the different types of LCD displays that can be used 
with the design. 

The touch screen interface section 30 utilizes an ADS7846E touch screen 
controller/data converter (not shown) in conjunction with two 74HC00 Quad NAND gates to 
translate the AM186EM microprocessor embedded synchronous serial interface signals to the 
signals required by the touch screen controller 48. Translation components are well known to 
those skilled in that art and therefore will not be described in detail. Suffice it to say that the 
AM186EM microprocessor has a 16 bit serial interface with a bi-directional data line and two 
mutually exclusive selects, but the touch screen controller requires separate data in and data out 
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lines with a single select. The touch screen interface section 30 also contains transient clamping 
devices (not shown) and filtering devices (not shown) for the touch screen. 

The power supply 32 provides the operating voltages as required by each section 
of the local control interface 12. The input supply is filtered for EMI and RFI emissions using 
5 conventional components (not shown). Overcurrent protection is also provided using 
conventional components (not shown). For interoperability with certain brands of controllers 
that use a full-wave-bridge power input structure to rectify a 24 volt AC input, a separate power 
connection may be provided. The primary supply is an LM2575-5.0 switching step-down 
converter (not shown) with a fixed output of +5 volts at 1 amp. This supply is used as an input 
10 source for all other power supply sections to generate secondary outputs. 
J !j The local control interface 12 may also include an Ethernet/phone line interface 

^ section 72. This section includes conventional interface circuitry 74, an Ethernet controller 76 

;© 

* -y with clock 78 and a phone modem 80. 

The preceding description of the controller interface 12, including the section 



J*. 

15* configuration and specific circuit components is merely exemplary. The precise configuration of 

• " 

' ,g the controller interface 12 will vary from application to application as desired. 

..sy 

" r C. Application Controllers 

As noted above, the present invention includes a plurality of application 
controllers 14, 15, 16 and 18 that control operation of corresponding applications, such as HVAC 
20 control, access control, system-wide sensors, security and lighting control. The various 
application controllers are typically capable of operating in stand-alone mode with no 
intervention from the local control interface 12.^^cordingly, eac h application controller 
includes generally conventional hardware and software components capable of providing stand- 
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alone control of the corresponding application. To provide control and system-wide integration, 
the application controllers are capable of exchanging communications with the local control 
interface 12. Accordingly, each application controller 14, 15, 16 and 18 includes generally 
conventional hardware components capable of exchanging messages over the communications 
5 network. 

The following paragraphs describe the general function of the various application 
controllers supported in the preferred embodiment of the present invention. Each of these 
application controllers is capable of communicating over a LonWorks network. 

The various HVAC application controllers, namely the DXU-1, DXU-2, AHU-1, 

lg FCU-1, FCU-2, FCU-3, FCU-4 and HPU-1, are similar in circuit design and general layout. 

'13 

; ;g Each of these HVAC controllers 14 generally includes sensor inputs 84, control outputs 86, 
auxiliary input/output points 88 and a zone sensor/display/interface 90. 

:© 

• The DXU-1 is a self-contained controller for a single zone direct exchange 

;^ ("DX") package, such as a rooftop DX unit. The DXU-1 controls DX units with up to two stages 
of heating and two stages of cooling. The DXU-1 maintains the temperature of a space to a 

'8*' 

r g defined setpoint The DXU-1 supports individual setpoints for occupied/unoccupied heat and 

M 

cool. Control is achieved by sequencing the heating and cooling stages based on the current 
space requirements. The DXU-1 includes digital inputs for fan status, mixed air low limit 
indication, smoke detector and filter status. A two wire serial interface pr^vHH fniLthf* 
20 thermostat and digital outputs in the form of triacgffoT^^ heat ing stages and t wo 



cooling stages. The DXU-1 energizes the fan when t here is a call for heating or cooling, and 
preferably can be overridden from a local thermostat E ach DXU-1 interfaces to a conventional 
local thermostat that provides a space temperature sensor, temperature setpoint adjustment, 

15 



occupancy override and a fan auto/on selection. The operating mode of the DXU-1 is normally 
determined by the local control interface 12. If desired, the DXU-1 may include a local backup 
schedule to determine operation when the local control interface 12 is unavailable. The DXU-1 



>nitors-4he status of thejfan. If the fan is energized and no air flow is detected after a 



predefined period of time^AeDXU- 1 turns off the fan and all stages of heating and coolin g. In 
addition, aa alarm is sent to jthelocal control interface 12. The DXU-1 will return to operation 



of smoke is detected, the DX U-1 turns off the fan and all stages of heating and cooling. In 
addition, an alarm is sent to the local control interface 12. The DXU-1 will return to operation 
after a reset. The DXU-1 further monitors the status of the air filter. An external pressure switch 
is wired to the input to determine when the filter becomes dirty. The DXU-1 reports an alarm to 
the local control interface 12 when the filter becomes dirty. The DXU-1 provides mixed air low 
limit protection. If a low limit condition exists, the DXU-1 turns off the fan and all stages of 
heating and cooling. In addition, an alarm is sent to the local control interface 12. The DXU-1 
will return to operation after a reset. The DXU-1 also monitors the runtime of the cooling stages, 
heating stages and fan, and reports an alarm to the local control interface when any one of them 
exceeds its predefined limit. In addition, the DXU-1 preferably reports an alarm to the local 
control interface when the space temperature drops below a predefined minimum or rises above a 
predefined maximum. The DXU-1 preferably sends a return to normal alarm when the space 
temperature returns to the proper range. 



economizer. The DXU-2 controls DX units with up to four stages of cooling, two stages of 
heating and an economizer. The DXU-2 maintains the temperature of a space to a defined 




after a reset. The DXU-1 also monitoi 




[uFfbij the presence of smoke^ If the presence 



The DXU-2 is a self-contained controller for a single zone DX package with an 
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setpoint The DXU-2 supports individual setpoints for occupied/unoccupied heat and cool. 
Control is achieved by controlling the economizer position and by sequencing the heating and 
cooling stages based on the current space requirements. The DXU-2 includes digital inputs for 
fan status, mixed air low limit indication, smoke detector and filter status, and analog inputs for 
mixed air temperature, return air humidity and supply air temperature. A two wire serial 
interface is provided for the thermostat and digital outputs are provide in the form of triacs for 
fan start/stop, two heating stages, four cooling stages and a two-position economizer. In 
addition, the DXU-2 may include an analog output to control a modulated economizer (if 
desired). With the exception of its ability to control four stages of cooling and an economizer, 
the operation of the DXU-2 is generally identical to that described above in connection with the 
DXU-1. 

The AHU-1 is a self-contained controller for a single zone air handler ("AHU") 
with a modulated economizer. The AHU-1 controls AHUs with modulated cooling, modulated 
heating and a modulated economizer. The AHU-1 maintains the temperature of a space to a 
defined setpoint. The AHU-1 supports individual setpoints for occupied/unoccupied heat and 
cool. Control is achieved by modulating the economizer dampers, heating valve and cooling 
valve based on the current space requirements. The AHU-1 preferably includes digital inputs for 
fan status, freeze indication, smoke detector and filter status, as well as analog inputs for mixed 
air temperature, return air humidity and supply air temperature. A two wire serial interface is 
provided for the thermostat. The AHU-1 also includes analog outputs for the heating valve, 
cooling valve and economizer. The AHU-1 also includes digital outputs for controlling the unit 
supply fan (in the form of a triac) and for controlling a two-position economizer (if desired). The 
AHU-1 energizes the fan when there is a call for heating or cooling, and preferably can be 
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overridden from a local thermostat. Each AHU-1 interfaces to a conventional local thermostat 
that provides a space temperature sensor, temperature setpoint adjustment, occupancy override 
and a fan auto/on selection. The operating mode of the AHU-1 is normally determined by the 
local control interface 12. If desired, the AHU-1 may include a local backup schedule to 
determine operation when the local control interface 12 is unavailable. The AHU-1 monitors the 
status of the fan. If the fan is energized and no air flow is detected after a predefined period of 
time, the AHU-1 turns off the fan and closes the heating and cooling valves. In addition, an 
alarm is sent to the local control interface 12. The AHU-1 will return to operation after a reset. 
The AHU-1 monitors an input for the presence of smoke. If the presence of smoke is detected, 
the AHU-1 turns off the fan and closes the heating and cooling valves. In addition, an alarm is 
sent to the local control interface 12. The AHU-1 will return to operation after a reset. The 
AHU-1 further monitors the status of the air filter. An external pressure switch is wired to the 
input to determine when the filter becomes dirty. The AHU-1 reports an alarm to the local 
control interface 12 when the filter becomes dirty. The AHU-1 provides mixed air low limit 
protection. If a low limit condition exists, the AHU-1 turns off the fan and closes the heating and 
cooling valves. In addition, an alarm is sent to the local control interface 12. The AHU-1 will 
return to operation after a reset. The AHU-1 also monitors the runtime of the fan and reports an 
alarm to the local control interface when the runtime exceeds a predefined limit. In addition, the 
AHU-1 preferably reports an alarm to the local control interface when the space temperature 
drops below a predefined minimum or rises above a predefined maximum. The AHU-1 
preferably sends a return to normal alarm when the space temperature returns to the proper 
range. 
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The FCU-1 is a self-contained controller for a two-pipe fan coil unit ("FCU") 
with a single coil for heating and cooling. The FCU-1 is designed to control commercial unitary 
HVAC equipment, and more specifically, FCUs with a single modulated valve and fan. The 
FCU-1 maintains the temperature of a space at a defined setpoint. The FCU supports individual 
5 setpoints for occupied/unoccupied heat and cool. Control is achieved by modulating the 
cooling/heating valve of a single coil two-pipe fan coil unit based on the current space 
requirements. The FCU-1 can control heating only, cooling only or heating/cooling fan coil 
units. Automatic seasonal changeover can be provided by a remote pipe mounted temperature 
sensor that is placed on the supply water line. The control is switched when the sensor detects a 
10 change in supply temperature between hot and cold water. The FCU-1 includes a digital input to 
j j| monitor equipment status, a two wire serial interface for a thermostat, an analog output for the 
.£ valve and a triac output for the unit supply fan. Each FCU-1 interfaces to a conventional local 
;, 41 thermostat that provides a space temperature sensor, temperature setpoint adjustment, occupancy 
. ' override and a fan auto/on selection. The operating mode of the FCU-1 is normally determined 

' : iLf 

by the local control interface 12. If desired, the FCU-1 may include a local backup schedule to 

jg determme operation when the local control interface 12 is unavailable. The FCU-1 monitors the 

-■M * . 

status of equipment within the unit. An external contact may be wired to the input to provide 
additional equipment safety interlocks. When the contact closes, the FCU-1 shuts the unit down 
and an alarm is reported to the local control interface. The FCU-1 also monitors the runtime of 
20 the fan and reports an alarm to the local control interface when the runtime exceeds a predefined 
limit. In addition, the FCU-1 preferably reports an alarm to the local control interface when the 
space temperature drops below a predefined minimum or rises above a predefined maximum. 
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The FCU-1 preferably sends a return to normal alarm when the space temperature returns to the 
proper range. 

The FCU-2 is a self-contained controller for a two-pipe FCU with a single coil for 
heating and cooling. The FCU-2 is designed to control FCUs with a single floating setpoint 
valve and fan. The FCU-2 includes a digital input to monitor equipment status, a two wire serial 
interface for a thermostat, a floating setpoint output for the valve and a triac output for the unit 
supply fan. The FCU-2 is generally identical in configuration and operation to the FCU-1, 
except that it is adapted to control a floating setpoint valve. Accordingly, the FCU-2 will not be 
described in further detail, reference instead being made to the above description of the 
configuration and operation of the FCU-1. 

The FCU-3 is a self-contained controller for a four-pipe FCU with a single coil 
for heating and cooling. The FCU-3 is designed to control FCUs with dual modulated valves 
and a fan. The FCU-3 maintains the temperature of a space at a defined setpoint. The FCU 
supports individual setpoints for occupied/unoccupied heat and cool. Control is achieved by 
modulating the cooling and heating valves of a dual coil four-pipe fan coil unit based on the 
current space requirements. The FCU-3 includes a digital input to monitor equipment status, a 
two wire serial interface for a thermostat, two analog outputs to control the valves and a triac 
output for the unit supply fan. Like the FCU-2, the FCU-3 is generally identical in configuration 
and operation to the FCU-1, except that it is adapted to control dual coil four-pipe fan coil unit. 
Accordingly, the FCU-3 will not be described in further detail, reference instead being made to 
the above description of the configuration and operation of the FCU-1 . 

The FCU-4 is a self-contained controller for a four-pipe FCU with a single coil 
for heating and cooling. The FCU-4 is designed to control FCUs with dual floating setpoint 
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valves and a fan. The FCU-4 includes a digital input to monitor equipment status, a two wire 
serial interface for a thermostat, two floating setpoint outputs for the valves and a triac output for 
the unit supply fan. The FCU-4 is generally identical in configuration and operation to the FCU- 
1, except that it is adapted to control two modulated floating setpoint valves. Accordingly, 
5 reference is made to the above description of the configuration and operation of the FCU- 1 . 

The HPU-1 is self-contained controller for liquid source heat pumps. The HPU-1 
is designed to control heat pump units with two-stage compressor, reversing valve and fan. The 
HPU-1 supports individual setpoints for occupied/unoccupied heat and cool. Control is achieved 
by sequencing the reversing valve and compressor stages of a liquid source heat pump in a 
conventional manner based on the current space requirements. The HPU-1 include a digital 
; jq input for monitoring equipment status, a two wire serial interface for the thennostat and digital 

£ • 

^ outputs in the form of triacs for fan start/stop, two compressor stages and a reversing valve The 

9 

M HPU-1 maintains the temperature of a space to a defined setpoint. The HPU-1 energizes the fan 
^ when there is a call for heating or cooling, and preferably can be overridden from a local 

jfffc thermostat. Each HPU-1 interfaces to a conventional local thennostat that provides a space 

ill* 

. jg temperature sensor, temperature setpoint adjustment, occupancy override and a fan auto/on 

;U 

selection. The HPU-1 preferably monitors the runtime of the fan and reports an alarm to the 
local control interface when the runtime exceeds a predefined limit. In addition, the HPU-1 
preferably reports an alarm to the local control interface when the space temperature drops below 
20 a predefined minimum or rises above a predefined maximum. The HPU-1 preferably sends a 
return to normal alarm when the space temperature returns to the proper range. The operating 
mode of the HPU-1 is normally determined by the local control interface 12. If desire, the HPU- 
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1 may include a local backup schedule to determine operation when the local control interface 12 
is unavailable. 

The ASM-1 is an auxiliary sensor module that monitors auxiliary sensors. Like 
other controllers, the ASM-1 controller is based on LonWorks networking technology. In the 
preferred embodiment, the ASM-1 is a stand-alone microprocessor based controller having 
analog inputs for outdoor air temperature 190, outdoor air humidity 192 and/or supply water 
temperature 194 (See Fig. 5). The values determined by these sensors are provided by the ASM- 
1 to the local control interface 12 for propagation to other application controllers. The ASM-1 
may also include demand meter 196, air quality 198 and other desirable inputs, as well as one or 
more auxiliary outputs 188. 

The ACU-1 is a self-contained controller for controlling and monitoring a single 
controlled access entryway, for example, to control access to various areas of a facility. The 
ACU-1 is capable of interfacing with one or two card readers 98 and/or keypads, an electronic 
door strike and a door monitor contact The ACU may also interface with a conventional asset 
tag reader to allow the control system 10 to monitor the movement of tagged assets. Each ACU- 
1 monitors and controls access to a single entry barrier through the use of an entrance card 
reader/keypad and an optional exit card reader/keypad. The ACU application controller 
preferably includes supervised inputs that provide for tamper detection. One input is preferably 
dedicated to monitoring door status, and another is dedicated to monitoring an exit request 
pushbutton. Two non-dedicated supervised inputs can be used for monitoring other tamper 
devices, such as a glass break detector or a motion sensor. The ACU application controller also 
includes digital outputs that control card reader indicators, such as LEDs and audible sounders. 
The ACU application controller provides 5 VDC outputs to power the card readers. A separate 
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power supply may be used if a different voltage is required. A relay output is provided to control 
a barrier locking device, such as a door strike or magnetic lock. Preferably, both normally open 
and normally closed contract are provided to accommodate barrier locking devices that lock 
when power is applied or devices that lock when power is off. Alarms are generated when the 
5 controller detects that a door has been propped or when a door has been forced open. Alarms are 
also generated if the two spare supervised inputs have been tampered with. 

The LCU-1 is a self-contained controller for lighting controls. The LCU-1 is 
capable of controlling commercial lighting circuits. Typical applications include interior 
lighting, parking lot lights and signage. In the preferred embodiment, each LCU-1 is capable of 

1|£ controlling eight individual lighting circuits based on the occupancy status of the zone. Control 

ill 

, : jg is providing by switching individual lighting relays (or contactors 92) for each circuit. Each 

£ . . . 

|= circuit preferably includes an override switch 94 that changes the occupancy status of the zone to 
! U "occupied" for a predefined period of time (See Fig. 6). The LCU-1 occupancy status is 
» ^ preferably determined by the local control interface 12. If desired, a backup schedule may be 

P rovi d e d on the LCU-1 to permit operation when communications with the local control 
; ig interface 12 have failed. The LCU-1 may also interface with a photo cell 96 in a conventional 

manner. 

The application controllers may be implemented using a wide variety of circuit 
components and circuit layouts. Accordingly, the application controllers may vary from 
20 application to application. In the preferred embodiment, all HVAC and lighting application 
controllers are realized on a common platform, while the ACU application controllers are 
realized on a different platform. For purposes of disclosure, a preferred implementations of the 
HVAC/lighting application controller and a preferred implementation of the access control 

23 



application controller will be described. The various application controllers may be realized on a 
single printed circuit board design by varying the component population as required. 

In general, the HVAC/lighting application controllers each include a processor 
section 100, an analog/digital input section 102, a digital output section 104, an analog output 
section 106, a room sensor/thermostat interface section 108, an intercontroller network 
interface section 110 and a power supply section 112. The processor section 100 preferably 
includes an MC143150B1FU1 (or equivalent) Neuron Processor 114 which executes a 
downloadable Neuron U C» program that contains the operating system, communications 
routines, data constants, hardware I/O drivers, and the application program unique to each 
controller type. The processor section 100 also includes a NeuroWire 3-wire serial 
synchronously-clocked simultaneous input/output interface comprised of 108 Serial Clock 
[SCK], 109 Serial Data Output [SDO], and IO10 Serial Data Iiqrot [SDI]. The protocol used in 
this interface is the same as the Motorola Semiconductor SPI or the National Semiconductor 
Microwire protocols and the actual operation of such is well known to those skilled in 
microcontroller-based designs. Each device controlled by this interface uses 108 [SCK] and 
109 [SDO] and/or IO10 [SDI] as required by each device and a processor I/O pin used as a 
chip select. The processor section 100 further includes an AT29C010N FLASH 
reprogrammable firmware memory chip 116 used to contain the Neuron "C" program for the 
given application controller; a 43256AGU Static RAM chip 1 18 used for temporary data storage 
and communication buffers; an address decode section 120 utilizing a 74HCT14 hex inverting 
Schmidt trigger (not shown) and a 74AC32 quad OR gate (not shown); a service switch 122 and 
LED 124 are connected to the Neuron processor to invoke and/or indicate the service state 
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condition of the Neuron processor; a DS181 1 power-on reset controller 126 used to ensure that 
the +5 volt power supply is stable and within proper operating tolerances and that the Neuron 
processor is initialized properly; a clock 128 having a 10.0 Mhz. crystal and discrete components 
causing the Neuron processor to operate at the proper frequency. 
5 The analog/digital input section 102 generally includes a LM358 sensor bias 

supply Op Amp (not shown) used to supply a precise bias reference to sensors that require bias 
such as a contact closure, or a thermistor that is used as one leg in a voltage divider with readings 
subsequently normalized by a program look-up table; an input bias and filter circuit for each of 
seven input channels (UI1 - UI3 and DI1 - DI4) (For example, channel UI1 is comprised of a 

1^ 1 0.0K ohm 1 % series resistor and a 0. 1 uF capacitor for filtering and transient dissipation. Also 

i'-O 

) , o there is an optional 1 0.0K ohm 1 % contact closure/thermistor bias resistor and an optional 1 0.0K 

as 

• +■ 

£ ohm 1 % input divider resistor populated as required by the particular controller types application 
: U program sensor needs); an LM4040-5 precision voltage reference (not shown); a TLC 1 542 or 

• ^ equivalent successive approximation Analog to Digital converter used to convert the inputs to 

digital values; a TCF6000D (not shown) and BAV99 (not shown) input transient clamp device 
; ; p used to limit the voltages of the input signals presented to the Analog to Digital converter (not 

iiu ■ 

shown); and a comparator (not shown) used to generate a chip select signal to the Analog to 
Digital converter (when used) when the processor asserts the [107] signal above 3.3 volts. To 
operate the analog input section, the processor and application program communicate with the 
20 AD converter via the Neuro Wire synchronous full-duplex peripheral interface comprised of a 
serial clock (SCK)P08], serial data out (SDO)[I09], and serial data in (SDI)[IO10] 5 and a chip 
select p07]. Suffice it to say that the processor clocks a command in to the converter for a 
particular channel to be converted while simultaneously clocking out the previous conversion 
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value. The digital input circuitry includes four voltage comparators with hysteresis connected to 
four discrete I/O lines to the processor. Each circuit has a negative-going input threshold of 1 .67 
volts and a positive-going threshold of 3.00 volts thereby providing 1.33 volts of hysteresis to 
prevent false triggering. The output is then coupled to a respective processor I/O line allowing 
5 the measurement of digital inputs without the cost or timing constraints of an AD converter for 
some applications. Both the AD converter and some or all of the digital input comparators may 
be used in some applications. 

The digital output section 104 includes an 8 channel TPIC6x595 Neuro Wire- 
based serial input parallel output open-collector driver (not shown) used to interface to up to 
10, eight triac output circuits or up to six BCX70 NPN transistors for direct coupling processor I/O 
I q lines to individual triac output circuits. Note that only one or the other approach can be used at 
£ one tune. The digital output section also includes up to eight triac output circuits each comprised 
; y of (output [TOl] for example) an MOC3012 optotriac coupler (not shown), a 2.21K ohm coupler 
< *_ LED current limiting resistor, a triac drive and snubber circuit (not shown), a 2N6073B 400 volt 
l$f 4 amp triac (not shown), and a metal oxide varistor (not shown).. 

; 'sir* 

: .£* 

] |Q The analog output section 106 provides three analog outputs, namely [AOl, A02 

and A03]. For [AOl], the analog output section includes an LM359 Op Amp based 2 pole low 
pass filter (not shown) with a gain of 2 that converts a high frequency pulse-width modulated 5 
volt digital waveform to a 10 volt DC voltage output. For [A02] and [A03], the analog output 

20 section includes a TLV5625 dual serial input voltage output digital to analog converter (not 
shown) coupled with an LM358 dual Op Amp (not shown) each configured for a gain of 3 to 
effect two additional 10 volt DC voltage outputs. This converter is interfaced via the 
synchronous serial interface. The design supports DA converters of 8/1 0/12 bits of resolution. 
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The room sensor/thermostat network interface section 108 supplies operating 
power as well as communication to the sensor and generally includes an LM317 adjustable 
voltage regulator (not shown) configured as a 38 milliamp constant current source; an LM339 
voltage comparator and associated discrete circuitry used to receive messages from the 
5 thermostat network and relay them to the Neuron processor; a dual BCX70 NPN transistor 
circuit used to sink the current source to ground to effect transmission of data to the room 
sensors as modulated by processor I/O line(s) [102] and/or [109] as required by interface type. 
The room sensor communicates back to the controller by sinking current in the same manner as 
the controller. Note that most of the time (even during communication) the network interface is 
1^ supplying the constant current to the thermostat reservoir capacitor thereby ensuring that the 
I • g thermostat has adequate operating power. The current protocol used is the proprietary Barber- 

£ Colman S-Link (Mu-Link) Sensor Protocol as defined in their confidential internal 
■J ihJ documentation. Suffice it to say that this is a half-duplex communication interface over a 

mutually sensed and modulated DC current-limited power line, the mechanics of which have 

15^ been practiced for many years and the actual operation of such is well known to those skilled in 

\ : $± 

. microcontroller-based designs. An alternative that has also been developed uses the same type of 

;3U ' 

mutual sensing and modulation in conjunction with a controller generated Manchester self- 
clocking (data with inferred clocking via bit cell transition polarity based on the previous data 
bit) command data stream with a trailing alternating clock/data bit stream for responses. This 
20 allows the sensor to be implemented with a very low cost microcontroller that derives all of its 
communication timing from the controller itself. 

The intercontroller network interface section 110 supplies external network 
communications to the application controller and generally includes an FTT10A Free Topology 
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Transceiver (not shown) and its associated circuitry or an LT485 EIA485 differential transceiver 
(not shown) and its associated circuitry, as desired. Alternatively, the intercontroller network 
interface may include a different interface such as the PLT22 power line transceiver. The actual 
protocol used is the Echelon Lon Works Manchester-based (for FTT10A or EIA485 interfaces) or 
5 thepchelon LonWorks special mode interface (for PLT22 or other power line interfaces). The 
Echel^LonWorksprotocoIs are well known to tEos§"s}«lled in microcontroller designs. The 
intercontroller network interface alsoinCluderaSud LED (not shown) for indication of the 
status of network activity via an LM339 comparator and controller transmission. 

The power supply section 1 12 supplies internal operating voltages to the 
lji application controller and generally includes a half-wave input rectifier diode (not shown), a 
J jg current limiting resistor (not shown) and input over current protection (not shown); and a +1 5 
£ volt supply using an LM317 adjustable linear voltage regulator (not shown), with its output set 
y M . by appropriate resistors. The voltage regulator does not use a bulk input capacitor, but instead 

.: m 

- * allows its output to "droop" between power line half-wave cycles. This substantially reduces the 

■ O 

internal heat generated. The power supply further includes a +5 volt supply using an LM78M05 

I U ■ 

; g* +5 volt linear voltage regulator (not shown); a comparator and DA converter reference circuit 

mW 

generating both 1 .67 volt and 3.3 volt bias. 

The ACU application controllers use a somewhat different circuit design than the 
previously described HVAC and lighting application controllers. The ACU is intended to be 
20 used in a distributed networked system with specific peripherals and communication medium. 
As such, the choices for supplied power and networking technology are made as part of the 
overall system design and may require external modules to implement. Each ACU application 

controller generally includes central processing section 150, card reader interface circuitry 152, 
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sensor loop interface circuitry 154, relay and digital output interface circuitry 156, intercontroller 
network interface circuitry 158 and power supply section 160. 

The central processing section 150 includes an Echelon 3150 Neuron CPU 162 
that provides the applications program, I/O point control, and interface to the Lonworks 
5 network via either the FTT10A Free Topology Transceiver or an EIA485 Transceiver, as 
described in more detail below. The Neuron processor 162 includes an EEPROM 167. The 
central processing section 150 also includes a 32K Byte Static RAM chip 166, and a GAL logic 
device 168 for address decoding an external EPROM 164, preferably in the form of a 27C010 
Flash ROM chip, for the storage of the operating software as well as the application program. 
Ifr The RAM chip 166 is used to provide additional file buffers for the ACU. The GAL logic 
' |! device 168 provides the OE*, the WE*, the Flash select, and the RAM select, and also 
;p generates the output port latch clock. The central processing section 150 also includes a 
IP service pin circuit (not shown). The service pin circuit has two functions: first it is driven by a 
; jpj push button autoconfiguration switch 170 to indicate to the Neuron processor 162 that it is 
% required to request service information as described in the Echelon Documentation, second it 

!o. 

j ij drives the service LED 172 in conjunction with a 270 ohm resistor. This initiates the self- 
configuration of the ACU with the LCI, as described in more detail below. The central 
processing section 150 further includes a system clock oscillator circuit 174 which generate the 
system clock used by the Neuron processor 162, preferably at 10 MHz; a reset circuit 176 

20 having a DS1233 low voltage reset controller (not shown), 2 4.99K pull up resistors (not 
shown) and a .OOluF timing capacitor (not shown) that is used to monitor the +5V power 
supply for proper levels; and a real time clock 178. 
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The Neuron processor 162 uses a Motorola 68HC05P6A I/O microcontroller 
180 for the direct interface to the card readers, keypads, and the supervised and unsupervised 
inputs (not shown). The ACU uses the larger address space of the Neuron processor 162 in 
order to have greater flexibility in the number of bindings and file buffers available. The I/O 

5 microcontroller 180 is connected to a system clock oscillator circuit 180 which generates the 
system clock used by the I/O microcontroller 180, preferably at 4 MHz. The Neuron 
processor 162 interfaces to the I/O microcontroller 180 via a seven-bit interface. The Neuron 
processor 162 queries the I/O microcontroller 180 for messages via the DATARDY and uses 
the DATASELO, DATAJSELl, and DATATYPE to establish what kind of data and then 
1^ uses the Neurowire (or SPI) port I/O object to send/receive data to/from the I/O 

i( p microcontroller 180. 

O The I/O microcontroller 180 buffers input data from the card readers) and/or 

! keypad(s), as well as providing analog and binary inputs. More specifically, supervised input 
; jjj channels are realized via an integral 8 bit 0 to +5 volt analog to digital converter (not shown). 

:»*- 

The interpretation of an input value is a function of the specific designed use of that input used 
i ilU. as a multi-state supervised input. Essentially, a voltage divider made up of the 4.7K ohm loop 
bias resistors and the end of line resistor installed in each detector is used to determine the state 
of the loop. The nominal end of line resistor value is 4.7K ohm 5%. The nominal state of the 
loop with 4.7K ohm is the Normal state. When the end of line resistor changes to 9.4K ohms, 
20 a contact open Alarm is reported. When the end of line resistor changes to 2.4K ohms, a 

contact closed Alarm is reported. When the end of line resistor changes to a short or an open, 
then a Fault is reported. A transient protector (not shown), plurality of 10K ohm series 
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resistors, and filter capacitors (not shown) are used to limit and filter the supervised inputs. 
The I/O microcontroller 180 also provides unsupervised inputs that are designed to detect 
binary contact closures to local common. They are realized via the same type input limiting 
and filtering circuitry as the supervised inputs. In this instance, the input values are read as 
5 digital inputs. The I/O microcontroller 180 further includes card reader track data inputs. The 
card readers* "0" and "1" inputs (Entry reader is used as an example) are connected to pull up 
resistors (not shown) and to the transient protectors (not shown) and filter capacitors (not 
shown). They then go to an inverting Schmidt trigger input device (not shown) and a reader 
type logic selection GAL (not shown) which is connected to two input port pins on the I/O 
lg microcontroller 180. In addition, the reader type logic selection GAL (not shown) is connected 

Jo 

£ to the I/O microcontroller's interrupt line. If the Wiegand mode is selected, both data input 

'I 

< O lines go to the interrupt. If the magnetic mode is selected only the clock (or "0") line is 

: $J 

^ connected to the interrupt. The reader modes are selected by a DIP switch (not shown). When 

, -n 

P the I/O microcontroller 180 receives these interrupts in conjunction with either of the two input 

;** 

IP* port pins, it buffers the track data from the reader. The second or exit card reader is interfaced 
! $J in the same manner. The reset controller 176 of the Neuron processor 162 is to connected to a 

pull up resistor (not shown) and to the I/O microcontroller's reset line via a diode (not shown) 

to synchronize the reset of the I/O microcontroller 180. In addition, the Neuron processor 162 

can directly reset the I/O microcontroller 180 alone via the IOl line. 
20 The ACU includes card reader interface circuitry 152 for interfacing the card 

reader(s) and/or keypad(s) (not shown) to the I/O microcontroller 180. This circuitry 152 is 

generally conventional and will therefore not be described in detail. 
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Similarly, the ACU includes sensor loop interface circuitry 154 for interfacing 
any external sensors (not shown) to the I/O microcontroller 180. This circuitry 154 is 
generally conventional and will not be described in detail. 

The intercontroller network interface circuitry 158 supplies external network 
5 communications. The network interface circuitry 158 generally includes an FTT10A Free 
Topology Transceiver (not shown) and its associated circuitry or an LT485 EIA485 differential 
transceiver (not shown) and its associated circuitry, as desired. Alternatively, the intercontroller 
network interface circuitry 158 may include a different interface such as the PLT22 power line 
transceiver. The actual protocol used is the Echelon LonWorks Manchester-based (for FTT10A 
ip, or EIA485 interfaces) or the Echelon LonWorks special mode interface (for PLT22 or other 

S power line interfaces). The Echelon LonWorks protocols are well known to those skilled in 

.£ ' 

JP microcontroller designs. The intercontroller network interface circuitry 158 also includes a dual 
|Jj . LED (not shown) for indication of the status of network activity via an HC86 logic gate and 
. p controller transmission. 

The relay and digital output interface circuitry 156 provides an output interface 

?»* 

■ 4 " 5 for controlling external devices, such as an electronic door strike. More specifically, the ACU 

-:3U 

has eight digital output bits generated via an AC574 latch (not shown). Seven of these eight 
lines go an MC1413D relay driver device (not shown). One of these seven drives the strike 
relay (not shown) for the door strike output. The other six supply open collector sinking digital 
20 outputs. The eighth line is connected to the base of a transistor (not shown) which drives a 
high frequency audio indicator (not shown) or a second relay (not shown) which can be used 
for a second door strike. The latch (not shown) is memory mapped within the Neuron address 
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space and the generation of the rising edge write strobe takes place within the GAL logic 
device 168 based on the address location, R/W, and E. The open collector outputs of the relay 
device driver are used to sink up to 50 ma loads. The six open collector outputs are transient 
protected and generally are used for indicators. 



including an input section containing a series diode and an input filter capacitor. This section provides a 
half wave rectified, filtered DC bus at approximately the peak of the input voltage. An LM2575M-5.0 
converter (not shown) provides an output of +5.0 V via an energy storage inductor (not shown), a 
commutating diode (not shown), and a filter capacitor (not shown). Most of the pins on the converter 
are connected to the groundplane for heatsinking purposes. A transient protector (not shown) provides 
transient protection because the +5V can be used to power the readers. The power supply section 160 
includes supply selection jumpers (not shown) that are used for the reader power selection. Regardless 
of the supply selected, there are transient protectors (not shown) and series limiters (not shown) for 
ACU supply protection. 



information to the application controller. These sensors are typically packaged with and often 
dedicated to use with the specific application. For example, a DX package unit may include an 
inside temperature sensor that provides inside temperature to the application controller. 



network- wide sensors that provide information to the control system 10, which shares that 
information with those application controllers that use such information. For example, the 
control system 10 preferably includes an auxiliary sensor module (ASM-1) (described above) 



The power supply section 160 is a step down (buck) switchmode converter circuit 




ty applications will include one or more integrated sensors that provide 



In the preferred embodiment, the control system 10 may also includes various 
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that is a LonWorks communications device which provides input information common to many 
HVAC control devices, such as outside air temperature, outside air humidity and supply hot 
water temperature. The local control interface 12 provides the sensed values to the appropriate 
application controllers over the network. By providing this information universally on the 
network, the need for separate sensors and individual analog inputs on each HVAC application 
controller is eliminated. 

The control system 10 also preferably includes a thermostat module (DTM-1) for 
interfacing thermostatic functions to HVAC equipment. The thermostat is a self-contained 
intelligent thermostat capable of communicating with various HVAC devices over the LonWorks 
network. A typical thermostat module system diagram is shown in Fig. 7. The thermostat 
application includes space temperature, setpoint adjust, fan override and occupancy override. In 
operation, the thermostat permits adjustment of the space temperature setpoint within predefined 
limits. The thermostat also preferably includes a push-button override that temporarily changes 
the occupancy status to "occupied/" 

The control system 10 may include various other sensor modules that provide 
information that is provided to a single application controller or that is shared with a plurality of 
application controllers across the network. 
III. Control System Operation 

As noted above, the control system 10 is essentially a distributed system with 
stand-alone application controllers 14, 15, 16 and 18 capable of operating in the absence of 
communication with the local control interface 12. The local control interface 12 has the ability, 
among other things, to monitor and adjust control variables in the various application controllers, 
thereby affecting operation of the various applications. The control system 10 includes various 
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software components that control operation of the local control interface and application 
controllers. The design and configuration of these software components will be well within the 
abilities of one skilled in the art after review of the operation of these components described 
herein. Accordingly, the software components will not be described in detail. 
A. Operation Overview 

The local control interface 12 and application controllers are capable of 
communicating over a variety of hardwire and/or wireless communication backbones. In the 



preferred embodiment, the present invention uses Echelon Corporation's LonWorks technology ^ 



as its communications medium ^Tie net work architecture is primarily master/slave with peer-to- 
10 peer (i.e., application controller to application controlle r) communica tions on ly as required by 

. 'sa ^ " — - 1 ~ — - s „ 

w q some applications. The local control interface 12 initiates most exchanges of communicat ion 

^ with the application controllers. All communication exchanges are initiated using LonWorks 

\ &J explicit messages with explicit addressing (i.e. direct 48-bit Neuron ID addressing). The local 



control interface 12 us es Standard Network Variable Typej^^^))for the standard data object 
5 l!j mo del values sent via explicit addressing to each application contro ller. The application 
] 'q controllers 14, 15, 16 and 18 and the controller interface 12 also provide LonWorks SNVTs for 
access to system features via third-party LonWorks devices. In operation, the local controller 
interface 12 does not directly manipulate the third-party device's SNVTs using LonWorks 
Network Management commands, however, third party networking tools can. Although the 
20 present invention preferably operates using LonWorks, the control system is well-suited for use 
with essentially any private protocols or "plug and play" open communications protocols. 

The local control interface 12 preferably includes two modes of operation, namely 
installer mode and user mode. Installer mode permits the user to access and control all aspects of 
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the local control interface. User mode permits access to only a limited set of command.^ thereby 
reducing the likelihood of accidental or mischievous modification of important system settii 



The precise amount of control permitted in user mode can vary from application to application, 
but in the preferred embodiment, user mode only permits access to and modification of/ 
temperature setpoints^rxonteaUers, existing schedules and view/acknowledge alarms. 



In the preferred embodiment, the local control interface 12 has the ability to 
divide the network of application controllers 14, 15, 16 and 18 into occupancy groups. The 
occupancy groups are used to permit collective control of the member application controllers in 
each group. For example, the lighting and HVAC applications in a given area can be grouped 
ljO together into a single occupancy group so that those applications can be operated as a group. 
; q l° ca * contr °l interface 12 of the preferred embodiment supports 16 occupancy groups. Each 

t3 p occupancy group includes a schedule and a list of up to 62 application controllers. The 
1 1| occupancy status of an occupancy group can be controlled by the corresponding schedule, via an 
* . access controller (such as an ACU-1 as described below) or manually using the local control 
jljj interface 12, 

* >( jn The local control interface 12 preferably supports up to 16 schedules, one for each 

i £ 

occupancy group. The schedules may be used for group occupancy control, timed operation of 
access control, door mode control, door free access control and lighting control. Each schedule 
preferably supports up to two start/stop time intervals for each day of the week and up to two 
20 start/stop intervals for holidays. The local control interface 12 maintains a database of up to 50 
holidays. Holidays can be preprogrammed or user defined after installation. 

The local control interface 12 also provides control configuration wizards that 
walk t he user through the steps required to jaopi tor and/or set the control variables for a 
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particular application controller. The wizards include easy-to-use graphical setu p screens for 
common configuration ite ms, such as occupied/unoccupied tempera ture setpoints an d backu p 

scheduling and fliflrm limits 



As noted above, the application controllers 1 4, 15, 16 and 18 operate in 
5 accordance with various control variables that are specified hy the user (orjhrough pre-set 



^tlefauit values^) For example, an HVAC application will include Ctemperature variable that sets 
the desired inside temperature for the corresponding area. As in many conventional control 
systems, the application controllers a re capable of operating in two distinct mo des, one when the 
area is occupied and one when it is not Fo r example, an HVAC application m ay include a first 
10 temperature setting Jo be satisfied when the area is occupied and a second tempera ture when the 

^ area k nnt QCCUBSd 



sp Although the application controllers are topically capable of operating in a stand- 



|tj alone mode, they are c apable of communicating with the local control interface 12 . Through 

- — 

* these communications, the local control interface 12 has the ability to set control variables values 

• .£») ■ 

• - 

if? within the application controllers m ftTgl^^cit messaflSfo and SNVTs for data jstnictme J This 
'jjjjj permits the local control interface 12 to affect operation of the various system applications. T he 
application controllers are preprogrammed with the data structure or format of all explicit 
messages associated with the controller type. This permits the application controllers to parse 
and understand the explicit messages. Alternatively, the applications may be downloaded with 
20 this information as necessary, for example, to a dd^new explicit messages or to modify existin g 
explicit messages^) 
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In addition to receiving explicit messages from the l ocal control interfac e 12, 
most of the application controllers are ca pable of sending text-based alanng) to the local control 
interface 12 to indicate extraordinary conditions. 

In the described embodiment, the local control interface 12 can support from 1 to 
62 application cont rollers. The local control interface 12 allows modification of inputs and 
setpoints for each application controller as well as^display of outputs for each controller. The ^ 



local control interface 1 2<jnaintains a controller database with certain information concerning 
^each application controller) When application controlle rs are added to the controller datab ase, 
they are given adefault name (i.e. Unit 1 AHU2) whi ch can be modified by the user to any 20- 
10 character s tring. The controller's name i s used when assigning it to occupancy groups and f or 

i \Q 

, .q alarm display. Each element in t he controller database preferably includes the following 
. x attributes: 



- M Name - 1 8 character ASCII description (user programmable) 

* Neuron ID - LonWorks 48-bit Neuron ID for device 



l|f Program ID - LonWorks Program ID for device (used as device type) 

it 

m 
m 



• :q Version ID - ASCII representation of controller's software version 



20 



Controller database records for ACU controllers preferably have the following additional 
attributes: 

Exit Group - Group whose occupancy count will be incremented when access attempt 
successful through exit side of ACU. Entry Group's count will be decremented. 
Entry Group - Group whose occupancy count will be incremented when access attempt 
successful through entry side of ACU. Exit Group's count will be decremented. 
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Free Access Schedule - specifies a Schedule for controlling ACU's free access status. 
ACU will be in Free Access when Schedule is active 

Access Mode Schedule - specifies a Schedule for controlling ACU's access mode 
Access Mode when Schedule active - mode (card, card+PIN or cipher) for ACU when 
5 Access Mode Schedule is active 

Access Mode when Schedule inactive - mode (card, card+PIN or cipher) for ACU when 
Access Mode Schedule is inactive 

Manual Free Access - forces Free Access active/inactive for ACU / 

Auto Add on/off - places ACU in to/out of Automatic Card Addition mode / 

Manual Access Mode - forces ACU into card, card+PIN or cipher access mode 



; . q B . Preprogramming of Local Control Interface 

, . *j£ As described in some detail above, theJocaLgonfrol interface 12 allows users to 



-Si! 



5 ; specify occupancy groups, schedules, hol idays and setpoints for the various application 
* controllers. This information may be entered into the local control interface 12 using its touch 

lit sc^n. If desired, this information ca n be entered into a PC-based program and downloaded into 
the local control interface 12 via the serial port in the AM186EM main processor. 

The control system 10 of the present invention permits self-configuration and 
integrated operation of application controllers of various types. This is preferably achieved by 
preprogramming t he control system lOfwith a configuration tableNthat stores profiles for the 
20 various controller types recognized by the system 1 0. Although t he precise information includ ed 
in these profiles wi ll vary for each application controller, these profiles gen erally include 
information about the input SNyTs, output SNVTs and configuration SNVTs of a ll supported 



controller types. The table and 



associated routines provide fo / lookup ~of SNVTs by namej 



ts 
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controller type and contr oller version ID. The LCI maintains an other table of supported data 
types which provides rang e, base data typ e, e ngineering units, en umerations (if applicable), su b- 
data types (for structured elements), s tep for increment/decrement and di splay routines for each 



^^^e.J A lLdata types used by the LCI have entries in this table. The se tables provide the 
5 local cont rol interface 10 with sufficient awareness of the application controller to monitor and 
affect its operation. 

In a preferred embodiment, each profile includes a record for each varia ble 
supported by th eapplication contro ller. The record includes a field for variable t ype, variable 
_name, ctisgla^name and variable-Hfimb^ The variables are p referably classified in one^ f three 
l|} different types- namely , input variab les, output variab les and iqput configuration variables. 

:q Input variables r epresent variables that can be sent to the application mntrolW by the local 

^ . ^ — 

control interface. Output variables represent variables that can sent bv the application controller 



to the local control interface . And finally, i nput configuration vafjaKlesa r e control variables that 

relate to operation of the application contro ller, but t hat are not routinely varied through lo cal 

control interface 12 co mmands or otherw ise. Each application controller is preferably pre-^ 

loaded with default values fo nall control <msM^pYhi s facilitates a utomated configuratio n, by / *f 

eliminatin g the need to provide these control variables with initial values. By way of example,-' 

the following is an implementation of the profile for an A HU-1 appli cation controller presented a 

"C" header file: , . „ L, J Oj«^l3 3 

20 typedef struct snvt_profile \ r-w-U *o.<L — . . 

UINT8 direction; // input, output or input config v 
UINT8 snvt_number; // LCI-defined SNVT number 
char *desc; // string describing SNVT 

25 UINT8 index; // index of SNVT on controller 

} SNVT_PROFILE; 
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SNVT_PROFILE far _based(_segname("_CODE ,r )) AHU1[44] = { 
{NV_INPUT,S_TEMP_SPACE, M Space Temperature",0}, 
{NV_INPUT,S_TEMP_SETP,"Temp Setpoinf',1 }, 
{NV_INPUT,S_OCC_I,"Occupancy Cmd V} , 
{NV_INPUT,S_LEV_DISC_I,"ResetRuntimes M ,3} ) 
(NV JNPUT,S_TIME_I, M System Time",4}, 
{NV_INPUT,S_TEMP_0UT,"0utsideTemp",5}, 
{NV_INPUT,S_LEV_PERCENT, ,, 0utsideHumidity n ,6}, 
{NV_0UTPUT,S_TEMP_P,"SpaceTemperature",7} J 
{NV_OUTPUT,S_HVAC_STATUS_AHU,"Unit Status",8) , 
{NV_OUTPUT,S_TEMP_P,"Effective Setpt M ,9}, 
{NV_OUTPUT,SjnMER,"Occ. Ext. Time Rem.",10}, 
{NV_OUTPUT,S_STATE_INPUT,"Input Status*\l 1}, 
{NVJ3UTPUT,SJ)CCJ,"C>ccupancyMode",12}, 
{NV_OUTPUT ; S_RUNTIME;'Fan Runtime",13}, 
{NV_OUTPUT,S_TEMP_P,"Supply Air Temp Out",14}, 
{NV_OUTPUT,S_TEMP_P,"Mixed Air Temp Out",15}, 
{NV_OUTPUT,S_LEV_PERCENT,"Retum Air Humidity", 16}, 
{NV_OUTPUT,S_FREE_COOL,"In Enthalpy",17}, 
{NV_OUTPUT,S_FREE_COOL,"OutEnthalpy",18}, 
{NV_INPUT_CONnG,S_TEMP_SETPT_I,"Occup. Temp Setpts.",19}, 
{NV^PUT^ONnCS.TEMP^IM/'Space Temp LimitVO}, 
{NV_INPUT_CONFIG,S_LEV_PERCENT,"Cool Prop. Gain M ,21}, 
{NV_INPUT_CONFIG,S_LEV_PERCENT, M Cool Integ. Gain",22}, 
{NV_INPUT_CONFIG,S_VOLT_I,"Cool Mm Output",23}, 
{NV_INPUT_CONFIG,S_VOLT_I, M Cool Max Output",24}, 
{NV_INPUT_CONFIG,S_LEV_PERCENT,"Heat Prop. Gain",25}, 
{NV_INPUT_CONFIG,S_LEV_PERCENT,"Heat Integ. Gain",26}, 
{NV_INPUT_CONFIG,S_VOLT_I,"Heat Min Output",27}, 
{NV^PUT^ONFIGS.VOLTJ/'Heat Max Output",28}, 
{m^_INPUT_CONnG,S_ECON, M EconomizerType ,, ,29}, 
{NV_INPUT_CONFIG,S_TEMP_ECON,"Econ. Setpt.",30}, 
{NV_INPUT_CONFIG,S_LEV_PERCENT,"Ecoii. Prop. Gain",31}, 
{NV_INPUT_CONFIG,S_LEV_PERCENT,"Econ. Integ. Gain",32}, 
{NV_INPUT_CONFIG,S_LEV_PERCENT, M Min. Fresh Air",33}, 
{NV_INPUT_CONFIG,S_FREE_COOL,"Free Cool Setpt.",34}, 
{NVJNPUT^ONFIG.S.VOLTJ/'Econ. Min Output",35}, 

. {NVJNPUT_CONFIG,S_VOLT_I,"Econ. Max Output",36}, 
{NV_INPUT_CONFIG,S_FAN,"Fan Type B ,37}, 
{NV_rNPUT_CONFIG,S_TEMP_ADJ,"Setpoint Adjust",38} , 
{NV_INPUT_CONFIG,S_EXTEND_TIME, ,, Occ. Extend Time",39}, 
{NV_INPUT_CONFIG,S_RUNTIME,"Fan Runtime Limit",40}, 
{NV_INPUT_CONFIG,S_TIME_I,"Occupied Time M ,41 }, 
{NV.INPU^CONFIGS.TIMEJ/'UnoccupiedTime"^}, 
{0,0xfT, m, ,0xfI}, 
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As noted above, the local control interface 12 is also preprogrammed with the 
format of the various explicit message that may be sent or received by the local control interface. 
This includes the data structures for the various ping messages to be sent to the application 
controllers, as well as the ping response messages received from the application controllers. 
Similarly, each application controllers is preprogrammed with the format of the various explicit 
messages that mayjre-s cnt o rye edag gcT by thakqpplication controller. 
B.^^ Self Configuration 

As noted previoystyTme control system 10 provides self-configuration of the 
various application controllers 14, 15, 16 and 18. In summary, self-confi guration is achieved 
W Jhrouph a series of c ommunications between the loca l^ control interface 12 and the ngs chL 
rj installed application control^ The self-configuration process 200 will be described in more 

4' 

le p detail with reference to the flow chart of Figs. 14A-14B. The communications exchange is 

;fU initiated by activation 202 o f the service control button on th e application controll er. This causes 

iff! ~ : ' 

* the application controller to send 204 a LonWork s "Service Pin" message that contains the 

l|£ controller's uniqu^eu^^^^ The local control interface 12 maintains a table jn nonvolatile 

'iu • ' ' 

iin memory that ha s a listin g for each ap plication co ntroller known tn th* \ Wt a\ rnn trol interface 

!** " i 

ij ' 

When the local control interface 12 recei ves the service pin message, it determines 208 whether 
it currently has a listing for the application controller's Neuron IH I f it does n ot, i t creates 210 a 
hsting corresponding to that Neuron ID . The local control interface 12 assi gns 212 the next 
20 available Device ID number to the new application controller and sends 214 a "Device 
Designation" message to the application controller . Tips messa ge contains the Device ID fox-t he 
application controll er. The application controller s tores the Device ID 216 in^nvalatilp 
memory for later use in sending messages to the loc al control interfa ce. The local control 
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interface uses the Device ID from application controller explicit messages t o determine which 
speci fic controller sent the message . The local control interface then sends 218 a "Controller 
In terface Identificatio n" message to the application controller, which contains the Neuron ID of 
the local control interf ace. The application controller stores 220 the local control interface 
5 ^NeuronJDLiruapnvolatile memory for later use in s ending messages to the local con trol interface. 

The local control interface 12 next places 222 the application controller into a common 

— - ^ " / 

LonWorks Domain and Subnet and assigns a unique Lon Works j&ode ID) The local control 
interface 12 sends 224 an "Update Domain" message to the application controller including the 
common LonWorks Domain and Subnet and the unique LonWorks Node ID , which are stored 

ljj. 226 in the application con trolle r. The Node ID matches the Deyjcfeil Lassigned earlie r. This 
j Q step is necessary to circumvent several inherent problems with LonWorks networking. First, 

^ since the local control interface uses LonWorks re quest/resp ons e messages for the tc Network 

■.m • ~ 

; W Variable Fetch" and '"Network Variable Update" operations, all nodes must have a unique 
^ subnet/node combination. Responses are alw avs^ent using subnet/node addressing requiring p j 

'esJ 

unique subnet/node for each node. Second, the local control interface pr eferably use s£gh elon ? g 
; jg Hosted N ode architecture which has the limitation of only bein g ^able to r e ceive evplirj t 

messages m one Domain, which requires each node to be in the same Domain. 

The local control interface 10 preferably includes ^ plurality of wiz ards that may 

be run to specify or adj u st the co ntro 1 variables for each of the aGri in^™ 1 coatmllgr^^ges 
20 These wizards faci litate modification and control of the application controllers by providing a 

Sjmglemenu driven GUI that aUo^sjieju»ftg-^ of all appropriate control 

variables. 
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C. Controller Supervision 

The local control interface 12 monitors the status of and transfers control variable 
values between application controllers using a periodic message/response methodology. In the 



preferred embodiment, the local control interface 12 periodically (e.g. once a second) sends a 
5 "ping" message to each application controller. If the application controller fails to send an 
appropriate response to a specified number of successive pings (e.g. three), it is considered to be 
in a failure state and appropriate action can be taken, for example, setting an alarm or generating 
a log. This process is also used to exchange information between the local control interface and 
the application controller using control variables embedded ir ihf * ping message and in the 
1^ responses to. ping m essages. The data structure of each ping message is preferably 

fS "~ """"" 

, q. preprogrammed into the local control interface 12. The ping message are preferably tailored to 

. ■«!»* 

jg correspond with the type of application controller to which it is sent. Alternatively, a single ping 
I M message universal to all controller types can be used. With this alternative, each application 

' : -in 

* controller may simply ignore the control variables that are not relevant to its operation. 

i S 

For example, in the described embodiment, the HVAC control ping is periodically 

\ 

;.ip sent by the local control interface 12 to each HVAC application controller (e.g. each DXU-1, 

iifU ■ 

DXU-2, AHIM, FCU-1, FCU-2, FCU-3, FCU-4 and HPU-1). The HVAC control ping 
preferably includes the system time and the occupancy mode for that specific controller. These 
control variables are sent to each HVAC application controller in an explicit message using 
20 SNVTs. A representation of the HVAC control ping is illustrated in Fig. 8. The HVAC 
controller's response demonstrates that it is still communicating with the network and can be 
used to return control variables to the local control interface in an explicit message using SNVTs. 
The HVAC controller's response preferably includes its Device ID, the outside temperature, the 
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outside humidity and the supply water temperature. A representation of the HVAC response is 
illustrated in Fig. 9. The information received in response from the HVAC controller can be 
used by the local control interface and/or propagated to other application controllers by the local 
control interface. 

With some application controllers, the ping response is nothing more than an 
acknowledgement which indicates to the local control interface 12 that the application controller 



is on line and has received the ping) For example, the access control ping message is 



periodically sent to each ACU. The access control ping preferably includes entry side mode, exit 
side mode, enable/disable flag for entry side, enable/disable flag for exit side, system date, 
system time, system day of week and ACU Device ID. The entry side mode and exit side mode 
fields indicate the access mode of the ACU. Typically, the ACU will be capable of operating in 
four different modes: 1) "card" mode, which requires only card validation to obtain access, 2) 
"card/pin" mode, which requires card validation and entry of a valid PIN to obtain access, 3) 
"cipher" mode, which requires entry of a valid four-digit code to gain access and 4) "PIN" mode, 
which requires entry of a valid PIN to gain access. A representation of the ACU control ping is 
illustrated in Fig. 10. The ACU response simply includes the I AC Device ID. A representation 
of the ACU response is illustrated in Fig. 1 1. 



Fig. 12 and a representation of the ASM response to an ASM ping message is illustrated in Fig. 
13. As shown, the response returns the outdoor temperature, outdoor humidity and supply water 
temperature control variables to the local control interface 12. As with all other messages, the 
control variables are presented as SNVTs. 




As a further example, a representation of the ASM control ping is illustrated in 
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As an additional example, a representation of the LCU control ping is illustrated 
in Fig. 19 and a representation of the LCU response to an LCU control ping is illustrated in Fig. 
20. The LCU control ping is intended solely to solicit a response from the LCU, thereby 
acknowledging its continued connection to the network. As shown, the control ping includes a 
5 message number indicating that the message is a control ping. The LCU response message 
returns only the unit number to the local control interface. 

D. System-wide Distribution of Process Points 

The local control interface 12 also has the ability to distribute various process 
point (or control variable) data to the application controllers. The process point data can be 
1^ obtained from sensors, such as those connected to the ASM-1 module. In the preferred 
. (j embodiment, the local control interface 12 receives the process point data from the ASM-1 

£ module, or other sensor, in response to the ping message sent by the local control interface 12. 

* J3 

? The local control interface 12 then transmits the process point data to the appropriate application 

; m 

; ^_ controllers via a network variable write using explicit addressing. The local control interface 12 
1;^ determines the application controllers that need the information by reviewing the controller! 
lg profiles provided in the profile database. Alternatively, the process point data can be presented 

to the appropriate application controllers by including it in the ping message sent to that 

application controller. 

E. Access Control 

20 The local control interface 12 oversees access at the various ACUs within the 

control system 10. In operation, the ACUs send an access request to the local control interface 
12 when a valid card reader or keypad entry is obtained from one of the ACU readers/keypads. 
A representation of the data structure of an access request message is shown in Fig. 15. The 
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access request is processed by the local control interface and a response is sent to the ACU 
indicating whether or not access is granted. A representation of the data structure of an access 
response message is shown in Fig. 16. The local control interface 12 also considers any affect 
access may have on related occupancy groups, for example, changing an '"unoccupied" status to 
"occupied." If appropriate, the local control interface 12 sends explicit messages to update the 
status of the appropriate occupancy group. This update will typically occur in the next ping 
message sent to each application controller with the occupancy group. Once a door is used, thl 
ACU sends a door used message to the local control interface 12. This permits the local control 
interface 12 to maintain a log of activity and a count of the number of persons in the zone. A 
representation of the data structure of a door used message is shown in Fig. 17. ^ _ 

The control system 10 is preferably capable of operating in five different access 
modes: 1) "card" mode, which requires reading of a valid card to obtain access, 2) "card/pin" 
mode, which requires reading of a valid card and entry of a valid PIN to obtain access, 3) 
"cipher" mode, which requires entry of a valid four-digit code to gain access, 4) "PIN" mode, 
which requires entry of a valid PIN to gain access and 5) "free" mode, which permits free access. 
When an access request is received, it is processed in accordance with the current access mode 
for that ACU. 

The local control interface 12 includes a database supporting up to 500 access 
cards. Each database entry preferably includes a card number (32-bit raw card number), a card 
name (18 character ASCII description), a PIN (4-digit BCD number used when card+PIN access 
is desired), a time/date field (containing the time and date on which the card was last used), a last 
door field (containing the last door at which the card was used) and an access group field 
(described below). Cards are added to the database in a general conventional manner, for 
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example, by presenting them at an ACU or via download from a PC or other similar device. The 
local control interface 12 is also capable of storing up to four distinct cipher codes. 

The local control interface permits cards to be placed into access groups. Access 
groups specify which doors a card may access and what time periods the card allowed access. 
5 The local control interface preferably supports at least 1 6 access groups. 

The local control interface also permits ACUs to control occupancy for 
occupancy groups, if desired. To provide ACU occupancy control, the local control interface 
maintains a person count by tracking the number of entries and exits into an area. If the person 
count is not zero, the local control interface sets the status of the occupancy group to "occupied." 

Although access is preferably governed by the local control interface, each ACU 
application controller preferably includes a local "per-door" database for validating access in the 
£ event of loss of communications with the local control interface. When the ACU send an access 

; M request to the local control interface 12 that is not answered within 14 second, the ACU will 

>.' : f! 

* attempt to validate the access using the local database. When the ACU validates an access 

jlfT. request locally, it will also preferably generate a time-stamped transaction log indicating the 

•■ !|* 

jg result of the access attempt. 

In a preferred embodiment, the ACUs also detects certain alarm conditions and 
sends appropriate messages to the local control interface 12 when an alarm event occurs. 
Preferably, the ACU monitors the status of the supervised inputs to determine when a "door 
20 propped," "door forced," or "input tampering" condition occurs. A door propped alarm is 
generated when an individual, who has gained access, leaves the door open for longer than a 
predefined access time. A door forced alarm is generated when the door is opened without 
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proper access authorization. A representation of the data structure of an access alarm is shown in 
Fig. 18. 

F. Lighting Control 

The local control interface 12 also manages operation of lighting applications 
within the building via one or more LCUs. As noted above, the LCUs are designed to control 
commercial lighting circuits, which may include interior lighting, parking lot lights and signage. 
In the described embodiment, each LCU controls the state of eight individual lighting circuits. 
The LCUs provides for eight lighting zones that permit group control of the lighting applications. 
More specifically, each circuit on each LCU can be associated with one or more of the eight 
lighting zones. The status of each circuit is affected by controlling the occupancy status of the 
corresponding lighting zone. The lighting zone associations for each LCU are configured via the 
local control interface 12. Each LCU maintains a database of the lighting zone associations for 
each of its circuits. The LCU controls the on/off state of each circuit based on the occupancy 
status of the zone associated with that circuit. The lighting zones can, in turn, be associated with 
occupancy groups, thereby permitting the occupancy of lighting zones to be collectively 
controlled with other applications within a given occupancy group. 

The local control interface 12 includes means for transmitting control messages to 
the LCU to advise the LCU of the occupancy status of the lighting zones. This permits the local 
control interface 12 to control the occupancy status of the lighting zones in accordance with 
occupancy group schedules maintained on the local control interface 12, as well as in accordance 
with other occupancy status changes, such as may be triggered by an access event. In operation, 
a change in occupancy status for a given zone, whether resulting from a schedule event or from 
another occupancy effecting event, is transmitted by the local control interface 12 to each LCU. 
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Eight different command messages are used to discern between the eight lighting zones. For 
example, a first command message is used to communicate the occupancy status of zone 1 and a 
second command message is used to communicate the occupancy status of zone 2. Upon receipt 
of the command message, each LCU reviews its database of lighting zone associations to 
5 determine if the command message is relevant to any of its circuits. If so, the LCU sets the 
on/off status of the appropriate circuits) in accordance with the occupancy status contained in 
the command message. Each LCU may also maintain a local back-up copy of the schedule to 
permit continued operation in the event of a local control interface or network failure. 

Each LCU also includes eight inputs used primarily for override switches. Each 
1^ override switch can be associated with one or more lighting zones so that actuation of the switch 
J g affects the occupancy status of these lighting zones. As with the circuits, the lighting zone 
|* associations of the inputs are preferably set via the local control interface 12, with each LCU 
i %J maintaining a local database of the associations for each of its inputs. In operation, actuation of 
> 3 an override switch cause the associated LCU to determine the lighting zones to which the switch 
'ffi is a member and affect the on/off status of all circuits on the LCU associated with that lighting 
g zone. The LCU also sends a peer-to-peer message to all other LCUs on the network indicating 
the change in the occupancy status of the particular lighting zone. Each of these other LCUs 
then affects the on/off status of all circuits on that LCU that are associated with the specified 
lighting zone. This permits integration of override events between LCUs without intervention 
20 from the local control interface. 

G. Alarms 

Various application controllers have the ability to send text-based alarms to the 
local control interface 12 to indicate extraordinary conditions, for example, several ACU alarms 
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were described in the immediately preceding section on Access Control. The local control 
interface 12 has the ability to display and store these alarms. Preferably, each alarm includes a 
unit name, time/date of occurrence and up to 40 characters of text. The text field can be used to 
provide meaningful text based descriptions of the alarm event. A representation of the data 
5 structure of an alarm is shown in Fig. 18. Although the alarms are preferably responded to 
manually, the local control interface 12 can be configured to provide an automated response 
when desirable, for example, the local control interface 12 can be programmed to repeatedly 
flash the lights in a zone in the event of a "door forced" alarm. 
H. Control Software 

lj^ As described above, the local control interface and the application controllers 

;q operate in accordance with installed control software. Typically, appropriate control software is 

r 

:s p preloaded into the local control interface and the application controllers. In some applications, 

6 

i|?J this may not be desirable or possible. Accordingly, the local control interface 12 preferably 

m 

■ :s includes means for storing a database of application controller software images and means for 

• O 

lj^ downloading the application controller software images into the application controllers. 
;g Generally, the a pplication controller software images will be downloaded into the application 

m 

controller during the self-configuration process to provide the application controller with the 



appli cable control software. The local control interface 12 can, however, be used to download 
<= " 

control software to the application controller even after self-configuration. This capability can 
20 be used to provide the initial installation of control software on an application controller or to 
update/upgrade the existing control software on an application controller. Similarly, the local 
control interface preferably includes means for downloading the control software of the local 
control interface and means for installing the control software on the local control interface. This 
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functionality is particularly useful in permitting customization and update/upgrade of the control 
software for the local control software. 

In control systems where control software is to be downloaded, the local control 
interface and/or the application controllers can be preprogrammed with only minimal basic 
5 networking and configuration functionality. This minimal programming permits the local 
control interface and/or application controllers to be installed on the network and provides for the 
downloading and installation of the control software. 

The local control interface 12 preferably includes means to permit the remote 
downloading of control software, including application controller software images and local 
10 control interface software images. This enables the lo cal contrd jnterface and the application 
> sq controllers to be updated/upgraded via a remote Internet, dialed or direct connection. 
.45 A flexible alternative to conventional control software is to preprogram the local 

! >4U control interface and/or application controllers with a generic programming language that 

1 91 

; ' permits operation of the device in accordance with custom control programs downloaded after 



self-configuration. The generic programming language provides an engine capable of 

■■ \¥> 

.ig controlling operation of a device in accordance with instructions contained in the custom control 

IS' 

program. In this alternative, the local control interface includes means for downloading custom 
control programs from a remote Internet, dialed or direct connection and/or for creating custom 
control programs, as well as means for downloading the custom control programs to the 
20 appropriate application controllers. 

The above description is that of a preferred embodiment of the invention. Various 
alterations and changes can be made without departing from the spirit and broader aspects of the 
invention as defined in the appended claims, which are to be interpreted in accordance with the 
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principles of patent law including the doctrine of equivalents. Any reference to claim elements 
in the singular, for example, using the articles a, an, the or said, is not to be construed as limiting 
the element to the singular. 
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